Update LFRic2LFric to store unique names for it's source and destination meshes - #729
Update LFRic2LFric to store unique names for it's source and destination meshes#729Ricky Wong (mo-rickywong) wants to merge 10 commits into
Conversation
|
The work to create the possibility of using meshes with the same name in lfric2lfric is very welcome. Thank you. Some questions to start with:
|
As far as the lfric code is concerned, once the meshes are loaded from file, the application can rename them to be stored as what name it likes internally. Everything else downstream of that point would just use the "stored" names that the application has decided on. I don't work with lfric_XIOS much, though I could well believe that there are names in the xml files which need to match with those being used in the application. That might be all that needs doing? However, there is another question which needs some consideration. Is the name of the mesh referenced in the output from lfric2lfric, if so then some changes may be needed in order to make the output match, i.e. if an application wants a file regridded and all the fields in that file are on a mesh called "dynamics" then the user would probably expect the regridded output to be on a similar name, i.e. "dynamics" rather than "dst_dynamics". |
…h the same mesh name
|
Thanks for adding the update to the canned test (example). Its great that this demonstrates and tests that the code works using meshes with the same name. (Note - the XIOS problems described above were found to be from using meshes that were inconsistent with the weights file, so this is now fixed). I believe that the generate_weights_lfric2lfric tasks is entirely separate from the lfric2lfric code (https://github.com/MetOffice/lfric_apps/blob/main/rose-stem/app/generate_weights/bin/generate_weights_lfric2lfric.py is a python script that calls ESMF). Hopefully it will be possible to modify this to allow it to also use meshes of the same name. I have looked in detail at the code and I cannot find any problems from a science perspective. I'm therefore happy for this to pass science review. |
cjohnson-pi
left a comment
There was a problem hiding this comment.
Passes science review
PR Summary
Sci/Tech Reviewer: cjohnson-pi
Code Reviewer: Matthew Hambley (@MatthewHambley)
Updates LFRic2Lfric code to use core changes in MetOffice/lfric_core#452 . These changes, along with those in the linked PR should allow LFRic2Lfric to use generated meshes for re-gridding, even if the meshes where identically named in the seprate mesh input files.
Linked PRs
Code Quality Checklist
Testing
Canned test in lfric2fric shows that the source and destination meshes are prepended with
srcanddstby lfric2lfric. This will satisfy the requirement for unique mesh name in the mesh collections, even if the input files have meshes named the same.Note:
A suitable test case for lfric2lfric to use where meshes of the same name are used in source and destination mesh files. The canned lfric2lfric test was modified so that it would attempt to read the same mesh for source and destination. i.e.
This failed in XIOS during the context creation of the output file. This test is out of scope, but may point to further work on lfric2lfric wrt XIOS output.
trac.log
Test Suite Results - lfric_apps - Apps_lfric2lfric_in_and_out/run1
Suite Information
Task Information
✅ succeeded tasks - 1218
Security Considerations
Performance Impact
AI Assistance and Attribution
Documentation
PSyclone Approval
Sci/Tech Review
(Please alert the code reviewer via a tag when you have approved the SR)
Code Review